1. Field
The present invention relates to processor design. More particularly, this invention is directed toward automatic generation of verification environment for processor design and verification.
2. Description of Related Technology
Electronic devices play an important role in our daily life, being used in various areas, e.g., entertainment (game consoles), communication (mobile phones), health care (diagnostic equipment), and the like. The functionality of such devices may use dedicated hardware units or processors. Dedicated hardware units may achieve high performance, low power consumption, and are usually employed in specialized devices. In contrast, their specialized function is disadvantageous in devices requiring changes due to, e.g., changes to the specifications, transition to the new standard, and similar events, where processors are preferred due to their programmability.
General purpose processor may be characterized as a processor which is not tied to or integrated with a particular application domain or piece of software. This flexibility comes with at the expense of size of an area on a chip, power consumption, and processing efficiency when execution a specialized application.
In contrast, application-specific instruction-set processor (ASIP) is a processor designed for applications, having specific requirements. By means of an example mobile devices, e.g., mobile phones require low power consumption, while requiring only specialized processing capability. Because the requirements of a target application are known, the design can be optimized for the requirement, e.g., low power consumption, size of an area on a chip, adequate processing efficiency, and other requirements known to a person of ordinary skills in the art. The optimization is achieved by implementing some software functionality in hardware and adapting the instruction set to the target application.
Development of an ASIP starts with determining requirements for the ASIP in accordance with the target application; the requirements being summarized in ASIP specifications. Traditionally, the development comprises several iterations usually done manually. In the first step of the iteration, tools for programming and estimation of the ASIP performance are developed from the ASIP specifications. Such tools may comprise e.g., higher programming language compiler, assembler, simulator, or profiler. These tools serve for a development of an instruction set. First, the required instructions are identified, by compiling the target application to be executed on the ASIP from the higher programming language in which the application is initially written. In this aspect, the term compiling is understood as translation of the higher programming language application into executable file, by means of a compiler, an assembler and a linker. The executable file is then executed by the ASIP. The simulator or profiler of the ASIP simulates the application compiled into the executable file so that debugging may be carried out before the ASIP design is committed to a physical processor implementation (target hardware technology), e.g., on a silicon chip, or a Field Programmable Gate Array (FPGA). The results of the simulation/profiling may indicate a need to change/optimize the instruction set and/or a need to change the ASIP specifications. Of course, any such change requires another iteration, changing of all the tools, a task demanding on both time and resources, since the changes are carried out manually.
In the next step, after the instruction set was stabilized, the optimal micro-architecture is designed in accordance with the ASIP specifications. Micro-architecture is an implementation of an architecture, wherein the architecture comprises an instruction set, registers and other components exposed to the programmer. Consequently, the micro-architecture design comprises design decision regarding, e.g., the number and types of Arithmetic Logic Units (ALUs), how many stages a pipeline has, connection to a memory subsystem, registers, and other design decision known to a person of ordinary skill in the art. After the micro-architecture is designed, the instruction set and the micro-architecture is re-evaluated in view of the target application and target hardware technology. This re-evaluation may affect only the micro-architecture, only the instruction set, or both. As mentioned supra, any such change requires changes of all the tools.
The above-mentioned complexity resulted in development of Electronic Design Automation (EDA) tools, automating the above-described tasks. One category of the EDA tools comprises tools for ASIP design. These tools eliminate or at least mitigate the design complexity, allow shorter development time, and deliver the resulting product in higher quality.
A class of the EDA tools is focused on generating programming and simulation tools, e.g., high level programming language (HLL) compiler, assembler, simulators, debugger, profiler, as well as hardware description in hardware description languages, e.g., VHSIC Hardware Description Language (VHDL), Verilog, and other languages known to a person of ordinary skills in the art in accordance with the ASIP specifications. To describe an instruction set and micro-architecture of an ASIP, Architecture Description Languages (ADL) have been developed. ADL languages can be divided into two main categories. The first category of languages allows modification of a limited part of the ASIP; the un-modifiable part is given by a template. An example of an ADL using templates is a Tensilica Instruction Extension (TIE), which is further limited to customization of the Xtensa processor core architecture. The second category allows to describe and modify all parts of ASIP. Examples of this category are Language for Instruction Set Architectures (LISA), nML, Codasip Architecture Language (CodAL).
The latter category of languages provides two levels of abstraction. The first level of abstraction, simpler and targeted at design space exploration (DSE), i.e., exploring optimal instruction set, is the instruction accurate description (IA). IA model is primarily aimed at the description of instruction set architecture (ISA) and defines instructions without any ties to the micro-architecture or target hardware technology. The hardware cannot be generated from the IA model, but is suitable for generating at least some of the programming and simulation tools.
The second level of abstraction, the cycle accurate (CA), is targeted at micro-architecture design for the target hardware technology. From the CA model a processor hardware description is generated in the hardware description languages.
As disclosed supra, the traditional design approach is to use the IA model to develop the description of instruction set architecture. The IA model is either designed by the user of the EDA tool, or is supplied by the EDA tool provider. Alternatively, the IA model may be produced by/for the specific EDA tool and supplied by a third party. Then, elements of the hardware description are added to the IA model, until the IA model morphs into the CA model, which is then used to generate the hardware description in hardware description languages. Once the hardware description has been generated, the model may be tested.
This traditional design approach has serious drawbacks. Since there is only single model used as an input for generating both the programming and simulation tools and the hardware description, the programming and simulation tools and the hardware description contain the same potential errors. As a consequence, testing and/or verification cannot find the errors, because the behavior of the hardware description and the simulators is the same. Therefore, a reference model for verification, additional simulators for testing, and/or a verification environment need to be created manually, which is time and resource demanding task. As discussed supra, an error found during testing may require restart of the entire cycle, starting with re-development of the IA model. Furthermore, the result of testing is limited to a binary outcome—a specific test either passed or failed. Thus, additional effort is needed to investigate and determine, what caused the failure.
Additionally, the single model may require separate and different descriptions for at least some of the programming and simulation tools. By means of an example, a description of a compiler is separate and different from a description of a simulator. Therefore, in case that a change/optimization is required for the programming and simulation tools, all descriptions have to be changed, which is both labor intensive and has a potential to introduce errors due to inconsistencies between descriptions.
Accordingly, there is a need in the art for an improvement in verification environment of the design process, providing a solution to the above identified problems, as well as additional advantages. An automatic processor design and verification that may use such verification environment is disclosed in co-pending application Ser. No. 14/183,482, filed on Feb. 18, 2014, by Zdenek Prikryl, et al., entitled A METHOD AND AN APPARATUS FOR AUTOMATIC PROCESSOR DESIGN AND VERIFICATION